Control systems incorporating PLCs (Programmable Logic Controlers) and DCSs (Distributed Control Systems) are frequently used to control real world processes by accepting inputs which typically originate from sensors such as, among others, those used to sense temperature, flow, level, radiation, light, movement, and pressure, and those used in generating outputs which are used to drive actuators such as hydraulic devices, valves, lights, and motors. Control systems can often be viewed as having a control component and an interface component, with one or both components having both hardware and software sub-components. Thus a PLC based device might utilize a digital PLC having embedded software as the control component (the “controller”), with an interface component (the “I/O interface”) (a) accepting signals from sensors and converting them into a form acceptable to the PLC, and (b) accepting outputs from the PLC and converting them to signals suitable as inputs to the actuators. In such systems, the controller and I/O interface are often connected by one or more paths (the “controller-I/O communication channel) to allow communication and control signals to pass between the controller and the I/O interface. Similarly, the I/O interface is, after the control system is installed in its operating environment, connected via one or more electrical paths (the “field wiring”) to the components from which the control system receives its inputs, and to the components to which the control system directs its outputs, with the I/O interface being provided with a plurality of connectors (“field I/O connectors”) which facilitate connecting the I/O interface with the field wiring. Many control systems will also incorporate a human-machine-interface (HMI) component comprising hardware and or software for facilitating operator interaction with the control system. FIG. 1 illustrates such a prior art control system 900 having a HMI 910, a controller 920, an I/O interface 930, HMI-controller communication channel 940, a controller-I/O communication channel 950, field wiring 960, and sensor/actuator components 970. In some instances, HMI 910 will be a general purpose computer running a windows based operating system and an application designed to facilitate operator interaction with the control system 900, and both the HMI-controller communication channel 940 and the controller-I/O communication channel 950 will be implemented via the use of a local area network coupling the HMI 910, controller 920, and I/O interface 930 together. Such a setup is shown in prior art FIG. 2 with HMI 910, controller 920, and I/O interface 930 each being coupled to a network hub 980.
It is often typical in development projects that a developer tasked by a customer to build a plant (including any control systems utilized therein) is given a set of requirements which the plant must satisfy before the developer is finished. This is particularly true for the plant control system, which plays a critical part in plant operation. At various stages of development, acceptance testing is performed to determine if the plant control system, to the extent that it is complete, continues to meet the requirements placed on the developer. During acceptance testing it is generally desirable to tie actions taken during the test and the outcomes of such actions to specific requirements so as to show whether the established requirements have been satisfied or not.
Generating test plans, implementing those plans, and correlating test results with requirements to verify requirement satisfaction can be tedious, time consuming, and prone to errors. Although methods and devices for testing control systems are known, they generally have individual strengths and weaknesses which make them more appropriate in some situations and less appropriate in others. A primary weakness of most methods and devices for testing control systems is the inability to properly verify requirement satisfaction. This inability may be at least partially due to the fact that, once installed in a plant, the controller cannot be subjected to as complete or rigorous testing as it can in a lab environment. Another possible factor is the difficulty in correlating large amounts of test results to requirements. Thus, there is continuing need to improve the test generation and requirement verification process.
In addition to the difficulties associated with testing and verification, training operators to use the HMI portion 910 of a control system can sometimes be difficult to achieve in a cost effective manner. Training operators on a “live” system (i.e. one already installed in an operating plant) is not a preferred method as it risks damage to the plant, wastage of material and generally requires that the plant be shut down or operated at less than full capacity during training.
Training on live systems can be avoided through the use of simulators. Such simulators exist, but typically have been performed on large scale mock-ups (i.e. a physical model/re-creation of at least portions of the plant) which typically require large investments in mock-up environments and dedicated spaces in which they can be assembled. It is also often difficult and expensive to keep the mock-up in sync with plant changes. Moreover, training costs tend to increase substantially if operators must travel to an offsite location to be trained. Such travel is often necessary as it is often more cost effective (as much as the use of a large scale mock-up can be cost effective) to utilize a single large scale mock-up and training staff for training operators of similar plants than to have a large scale mock-up and training staff at every plant.
Thus there is a continuing need for improved training systems which allow operators to be trained to operate a plant control system without the use of large scale mockups and/or the necessity to travel away from the plant.